昨天提到了兩種邊緣函數(Lambda@Edge & CloudFront Functions) 範例程式碼，今天我們延續昨天的程式碼繼續往下談起。

Lambda@edge

無論是 Lambda@edge 或 CloudFront Functions，基本的概念大概是:
開發程式碼 --> 測試 --> Deploy 到線上 --> 運作 (不是出包，呸呸呸)

開發程式 + 基本測試

以我提供的範例程式碼，我是這樣設定 Lambda@edge :

• 登入 Lambda console，切換至 us-east-1 region (極為重要)
• 建立 lambda (選擇的 template: from scratch)
• 貼上程式碼
• 設定一組測試的 pattern，以本次的目標的話，我們將測試的網址(uri)，從 '/index.html' 改為 '/'，
• "記得" 先 deploy後(這樣程式碼會被儲存)，再點選測試
• 確認測試結果符合預期? 如果 OK，來 deploy 吧。
  

Deployment

• 先選擇到"Configuration"，點選 lambda 主動幫你建立的 role，開到 IAM 的 Console 的這 Role
  
• 確認該 Role 的 Trust Relationship 中有允許被 'edgelambda.amazonaws.com' 給 Assume
  
• (回到 Lambda Console) 選擇 Add Trigger，選擇 CloudFront，點選 Deploy to Lambda@Edge
• 選擇對應的 Distribution 的目標 Behavior 的對應 trigger point(這邊我們用 "origin request")
• 點下 Deploy，開始 Deployment 進行(一般來說很快，通常不會超過一分鐘)。
• 也可以切換到 CloudFront Console，檢視該 Distribution 的該 Behavior，此時已經可以看到被關連上了。
  

CloudFront Functions

相較於 lambda@edge 需要切換至 Lambda Console，CloudFront Functions 完全停留在 CloudFront Console 編輯。

開發程式 + 基本測試

• 點選左側選單的 CloudFront Functions 後，創建新的 Function，貼上程式碼。
• 不同於 Lambda@edge，CloudFront Functions 可以 'Save'，接著就可以存，存完之後才能理所當然地透過 Test 測試到新程式碼。
• 測試符合預期後，就可以 deploy 到對應的 Distribution 去。當然，如果你天生神力，也可以不測試就直接 deploy
  

額外關於 Lambda@edge & CloudFront Functions 的幾點經驗分享

• 詳細的官方比較，可以看這篇文件。大概念: Lambda@edge (以下稱 l@e) 相較於 CloudFront Functions(以下稱 CFF)的功能強大的多，但兩者因為功能不同 & 能被 Trigger 的點不同，自然而然有所差異。L@e 可以執行的時間較長，CFF則強調輕量/快速。
• 因為 Cache 可能發生在 Edge(PoP)，也有可能發生於 Regional Edge Cache。所以遇到 Cache Hit(Hit from CloudFront) 時， 設定在 Origin Request & Origin Response 的請求，將不會被觸發。
  下面這張圖強烈建議再看一次
  
• l@e 的 Quota 是依不同 Region "分開"計算，且 Concurrency 會跟該 Region 的 Lambda 共用。
• 如果你的請求可能在短時間內大量湧入，使用 l@e 很容易遇到 Throttle(503 Error)。記得申請提高
• 因為有被 Throttle 的能，所以我個人 完全不建議 用 l@e 來自行實作 WAF 功能(ex: 檢查客戶標頭，不標頭不符就 OOXX)，這類事情還是留給專業的來。
• CFF 如果寫得爛，又多次呼叫，還是有可能會被 Throttle.
• 如果你有配置 Origin Groups，那麼當 Origin Group 有 failover 切換到另一組的時候，設定在 Origin Request 的 l@e 也會隨著切換而被再次呼叫執行，但因為 CFF 不會參與這塊(早就執行完了，所以不會被重複執行)
• l@e 程式有版本號，新版本上線不會影響原本正使用中的版本；但 CloudFront Functions Deploy之後就是正式版本，使用中的也就跟著更新。
  
  
• 因為忘記給寫 CloudWatch Logs 的權限，而沒有 Log 產出，是使用 l@e 的一個常見錯誤(失誤)。(比方說限定了僅能寫入 us-east-1 region 的 CW Logs，但請求在 ap-northeast-1 region 被觸發)
• l@e 和 CFF 在 aws doc 的程式碼 和 Blog 中的範例都是很值得參考的指標(也可以想想為何設定在特定的點觸發)
• l@e 和 CFF 都有一些資料無法存取，或者是只能讀不能改(read only)的各種限制，在規劃服務時需要額外注意。
• 無論是 l@e 或 CFF，本身基本上都沒有 Retry 機制(套用 Origin groups 的不算)，所以如果要使用，要從 Client 端規劃 retry/容錯機制。

Okay，這就是我今天的分享，有任何想法、疑問，歡迎留言告訴我。

--

電腦還是壞的，只好繼續貼女兒照片。這動作，是草帽海賊團?